The examples used in this article are available for download. We recommend creating the objects and typing in the code yourself, as this will help you understand the material. However, if you are short of time, you can simply install the “PublishQueueViewer” package (available in the package folder)  and have it all ready in seconds. You can also use it later on if you actually need a Publish Queue Viewer application.

The PublishQueueViewer.zip Sitecore package will add the “SDN5 Samples” folder to the Sitecore menu.  This menu will include the “Publish Queue Viewer” application. If you find the application useful, you can move it to Administrative Tools folder or somewhere else.

The heavily-commented source code is also included. We recommend that you use Visual Studio .NET for viewing and modifying the code; however, nothing prevents you from using your favorite text editor and the cs.exe compiler available in the .NET Framework SDK.

Note: The article itself doesn’t include ‘checkpoints’, that is it doesn’t tell you when to save, compile and inspect the results. It is advised that you do it at least once per each control added

First, we will define the problem we plan to solve with this application in order to list the requirements and then decide which controls will be used for which purpose.

Our goal is to create an application that will allow Users to see the list of Items that will be published upon the next Incremental Publishing procedure, that is the list of Items that were changed since the last publishing and which do qualify for publishing (keep in mind the Publish/Unpublish date, Lifetime and publish restriction).

The Sitecore API has a number of useful methods to access the required data. This method will be the main source:

public ID[] GetPublishQueue(DateTime  from, DateTime to);

The method returns IDs of all Items eligible for publishing for the given time period. Thus our first requirement is as follows: We need to provide means for a User to set the ‘from’ and ‘to’ dates. Then we need to apply some custom logic to filter the Items and display the results. The actual use of the Sitecore publishing API is beyond the scope of this article, so feel free to look through the PublishHelper class in the examples for the article if you’re interested. The class itself is also documented.

The second requirement will be to display the actual list of Items along with some information, like their path, version and language. In addition to this, we would also like to use a separate control to visualize the location of those Items in the content tree.

The next task will be to create more generic User interface goals: provide a convenient way of interacting with the application.

We will use a time machine to look at the completed application to give the overview of controls used.

1. A Listview control is used to display the list of Items to be published

2. A Context Menu supplements Listview, allowing some additional operations, like opening the selected Item in the Content Editor or changing appearance of the list view. 

3. A Status bar displays the number of Items currently in the Listview. 

4. A Toolbar provides access to application-wide functions. 

5. Two DatePicker controls allow Users to select the time interval. 

6. A DataTreeview paired with a DataContext visualizes the Item’s location in the content tree. When a User selects an Item in Listview on the right side, the tree view automatically shows the Item’s position in the content tree. 

7. A VSplitter allows a User to distribute the “screen real estate” between the TreeView on the left side and ListView on the right.

Next sections will guide you through all the controls listed above. For better understanding, you should read them in order.

Listview is the main control of the application. It displays the list of Items to be published and provides some interaction with them, for example, double clicking the Item will open it in the Content Editor.

First of all, we will add the Listview control itself:

We want to display the Item’s name along with the additional properties, such as its path, language and version. To perform that in XML terms, add the <ListviewHeader> element and populate it with the ListviewHeaderItems:

As both the number of Items and their path can become pretty big, we also want to handle scrolling properly – wrap the Listview control in the ScrollBox:

We’ve finished the declarative part of adding the Listview control. Switch to the code-beside class to populate Listview with Items.

We would also like to provide some way to interact with the Users. When a User double clicks on an Item, we will open the Content Editor with the Item selected. To achieve this, you should do the following:

1. Add the ‘DblClick’ attribute to the Listview and set it to ‘OnOpen’
   
   <Listview ID="ItemList" View="Details" DblClick="OnOpen" …>
2. Add the OnOpen method to the Code-Beside class.
   protected void OnOpen()
   {
      // Ensure that the user has selected an item in Listview
      if (ItemList.SelectedItems.Length == 0)
      {
         Context.ClientPage.ClientResponse.Alert("Please select an item first");
         return;
      }
    
      // Extract the values from the selected Listview item
      ListviewItem selectedItem = ItemList.SelectedItems[0];
      Item current = source.Items[selectedItem.ColumnValues["path"] as string];
      string id = current.ID.ToString();
      string language = selectedItem.ColumnValues["language"] as string;
      string version = selectedItem.ColumnValues["version"] as string;
    
      // Open the item in content editor
      OpenInternal(id, language, version);
   }

The OpenInternal() method uses the internal communication system to open the Content Editor with the given Item selected. Please browse the source code if you’re interested in this technique, it is only 6 lines long.

To provide even more ways of user interaction we will add the ContextMenu control and bind it to the Listview.

We’ve already implemented the methods that will be called from the Context Menu and want to provide another way of interacting with the application.

1. First, declare the Context Menu:
   
   <ContextMenu ID="FileListContextMenu">
   </ContextMenu>
2. To instruct the Listview control to popup the context menu when needed (that is when it is right-clicked by a User), add the following attribute to the Listview declaration:
   
   ContextMenu="show:FileListContextMenu"

3. Populate the context menu with Items. Again, all declarative:

   
   
   <ContextMenu ID="FileListContextMenu">
      <MenuItem Icon="Applications/16x16/document_view.png" Header="Open"            
                 Click="OnOpen" />
            <MenuItem Icon="Applications/16x16/refresh.png" Header="Refresh"
                       Click="Refresh" />
            <ListviewViewsMenuItems Listview="ItemList"/>
         </ContextMenu>

The first two Items are regular menu Items – the Icon and Header attributes set the appearance, and Click defines the action. Since we’ve already added the OnOpen and Refresh methods, we don’t need to add anything to the code-beside class.

ListviewViewsMenuItems is a special menu control that allows a User to modify the appearance of the Listview control. We’ve set it to be “Details” by default in ListView declaration. However, this menu will allow a User to choose from ‘Icons’, ‘List’ and ‘Details’ options.

There’s no built-in status bar control, but it can be easily emulated by a few lines of XAML markup:

After that, add the literal to the code-beside class:

And update the FillItemList() method that fills the Listview control:

The status bar will show the number of Items in the list view.

Note: To add more sections to the status bar, simply increase the number of columns in the Grid Panel and add more <Border /> elements.

To allow users to select a specific time interval we will use two DatePicker controls:

The ‘Start’ and ‘End’ properties provide access to the date picker values, since  DatePicker stores its value in ISO date format, but the publishing API requires DateTime parameters.

The date of the last similar publishing is used as a default beginning date, and the next day is used as an end date.

In our application, the DataTreeview control visualizes the Item’s location in the content tree. When a User selects an Item in Listview on the right side,  the tree view automatically shows  the Item’s position in the content tree.

In section 3 , we’ve manually created ListviewItem objects to populate the listview control. This section illustrates a different approach: using DataContext and data controls. The DataTreeview will automatically populate itself with children basing on associated DataContext.

DataContext is added just as any other control, despite the fact that it is invisible to the end user:

We will setup the data context to show all Items in the master database, that is all children of the ‘/sitecore’ Item. The following code is added to the OnLoad() method:   

Dataview is an essential component used by data context internally to navigate Items. There is MasterDataView that is used to navigate regular Sitecore databases (along with the RecycleBinDataView subclass, DomainDataView and FileSystemDataView).

Dataviews are registered in web.config:

That is why setting DataViewName to “Master” instructs DataContext to use MasterDataView.

The DataTreeview control is derived from the regular Treeview control to display Items provided by the data context. Since we’ve set up the data context in the previous chapter, now we need to create  DataTreeview and bind it to the data context

This is similar to defining the Listview and regular Treeview controls: we define the control itself and declaratively populate its header. The only significant difference is that we bind the tree view to the data context. From now on we can forget about the tree view itself and only use the data context to navigate the data, and the tree view will automatically update itself accordingly.

As a final cut, we will add a little eye candy to the tree view, making the Content Editor like gradient to it.

Note that the gradient style is actually applied to the embellishing scrollbox control, instead of the tree view itself.

We’ve set up and initialized the data context,  created DataTreeview, and bound it to the data context. At this point, the tree view itself is fully functional – it shows the content tree starting from the /sitecore root Item and can be navigated by the User.

However, there’s still one design goal left – to visualize the location of publish queue Items in the content tree. We will implement the following behavior: when a User clicks on an Item in the list view, the tree view will set focus to the same Item in the content tree, thus effectively showing its location.

To start, we will subscribe to the OnSelectionChanged event of the list view:

The actual event handler is simple. All we need to do is to retrieve the Item selected in the list view and then select it in the data context as well.

Vertical splitter control allows a User to distribute space between other User interface controls. We will add it between the tree view and list view controls, thus enhancing the usability of our application.

 Notice a few things regarding the usage of VSplitter control:

1. It is only supposed to be used inside the GridPanel control 
2. When using vertical splitter, GridPanel should have the “table-layout:fixed” style attribute set 
3. Do not forget to increase the number of columns in the GridPanel when adding a splitter. A s plitter is a control like treeview or listview. 
4. VSplitter should have its ID attribute set even if you do not reference it from the code-beside class. A nice feature of the splitter is that it automatically stores its location on the form for each User, that is the splitter remembers each User’s position, so that each User can have a different form layout. As a result, however, you should always assign an ID to a splitter, so that it can store and retrieve its settings

The Width and Style attributes control the splitter appearance.

The target attribute determines which control will be resized by the splitter. We set target=”left”, so that VSplitter can modify the width of the DataTreeview control if the User changes it using the splitter  and load the modified value the next time the application is started (actually not the width of the DataTreeview control itself, but the width of the scroll box containing the tree view). If we change it to ‘right’, the width of the ListView control will be used instead. In this setup, it doesn’t actually matter which one you choose, but since it doesn’t have the default value, you should pick one.

The article covered the process of creating a complete production quality application using some of the advanced UI controls like ListView, DataTreeview and DataContext, ContextMenu, ToolBar, DatePicker, VSplitter and Status Bar.

If you still doubt about the advantages of the new XML UI model, consider this: 

1. I t took only 80 lines of the declarative markup and about 200 lines of the code-beside event handling code (excluding the use of API publishing), all heavily commented and highly reusable.
2. The application provides a rich user interaction, but yet we haven’t written a single line of the JavaScript code. 
3. We’ve inherited the stylish look and feel of Sitecore UI without any extra effort.